AWSの別アカウントにプライベートホストゾーンとACMの証明書を作成してみた作成してみた

t.honda

2022.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

既に存在するルートドメインの配下にサブドメインを作成したい、そのサブドメインは別アカウントに作成し、ホストゾーンの種類をプライベートにしたいというケースがありました。それに加えて、作成したサブドメインで使える証明書の発行も必要でした。

いろいろなやり方があるかと思いますが、今回は以下のような構成を取りました。ルートドメインは「example.info」で「アカウントA」に存在し、別アカウントの「アカウントB」にサブドメインと証明書を作成するものとします。

# アカウントA
- Route53
    - example.info ・・・ 既に存在するルートドメイン
    - dev-xxx-public.example.info ・・・NSレコードを定義してアカウントBから委譲

# アカウントB
- Route53
    - dev-xxx-public.example.info ・・・ 新しく作成した「パブリック」ホストゾーン。証明書を紐づける。
    - .dev-xxx-public.example.info ・・・ 証明書のCNAME
    - local.dev-xxx-public.example.info ・・・ 新しく作成した「プライベート」ホストゾーン
- ACM
    - *.dev-xxx-public.example.info ・・・「パブリック」ホストゾーン配下のワイルドカード証明書を作成

ここまでで大体やったことは説明した感はありますが、表などを入れて、もう少し細かく説明していこうかと思います。

ドメインとRoute53について

最初に書いたように、今回は

ルートドメインの下にサブドメインを作りたい
サブドメインは別AWSアカウントに作りたい
更にサブドメインはプライベートホストゾーンとしたい

というケースでした。これらは以下の記事のように親となるホストゾーンへの委譲を行うことをまずは検討しました。

Route 53でサブドメインを別のHosted Zoneに権限委譲する

少々検討が必要だったのはサブドメインで使う証明書の作成でした。証明書はACMで作成することはできますが、プライベート用で作る場合はプライベートCAの作成が必要であるのと、料金がそれなりに掛かるなど、パブリックな場合と比べて手軽さに欠ける印象です。

(参考 : [新機能]ACM Private Certificate Authorityを試してみた)

今回は「パブリック」ホストゾーンも存在しえるケースだったので

作りたいサブドメインの親となるドメインを作成し、親をパブリックとする
1.のパブリックな「親」ドメインをルートドメインの下につける（つまりサブドメインはルートドメインの「孫」となる）
証明書は1.のパブリックとした「親」ドメインに紐づくようにして、パブリック証明書としてACMで作成する
証明書はワイルドカード証明書として、サブドメインでも適用できるようにする

としました。

これらを踏まえ、アカウントA・アカウントBのRoute53の定義は以下のようになりました。なお「説明」欄は本記事用に追加したものであるのと、定義を追加・変更した項目のみ記載しています。

アカウントA

ホストゾーン

ドメイン名	タイプ
example.info	パブリック

example.info ホストゾーンの詳細

レコード名	タイプ	値	説明
example.info	NS	xxx.org. xxx.net. xxx.co.uk. xxx.com.	既に存在するルートドメイン。
dev-xxx-public. example.info	NS	aaa.org. aaa.net. aaa.co.uk. aaa.com.	アカウントBに作成した「パブリック」ホストゾーンから委譲するためのレコード。

アカウントB

ホストゾーン

ドメイン名	タイプ	説明
dev-xxx-public.example.info	パブリック	「パブリック」証明書を紐づけるホストゾーン
local.dev-xxx-public.example.info	プライベート	作りたいプライベートホストゾーン

dev-xxx-public.example.info ホストゾーンの詳細

レコード名	タイプ	値	説明
dev-xxx-public.example.info	NS	aaa.org. aaa.net. aaa.co.uk. aaa.com.	アカウントAに委譲するレコード。同じ値をアカウントAにコピーする。
_zzzz1111aaaaa.dev-xxx-public.example.info	CNAME	_1111xxxxx.acm-validation.aws.	ACM証明書からコピー。後述する。
local.dev-xxx-public.example.info	NS	bbb.org. bbb.net. bbb.co.uk. bbb.com.	「プライベート」ホストゾーンから委譲するためのレコード。

local.dev-xxx-public.example.info ホストゾーンの詳細

レコード名	タイプ	値	説明
local.dev-xxx-public.example.info	A	xxx.elb.ap-northeast-1.amazonaws.com.	サブドメインでアクセスしたい先のELBなど
local.dev-xxx-public.example.info	NS	bbb.org. bbb.net. bbb.co.uk. bbb.com.	直接の親の「パブリック」ホストゾーンに委譲するレコード。同じ値を「パブリック」ホストゾーンにコピーする。

上記のRoute53の定義について、下から見ていくと分かりやすいかと思います。

一番下の「local.dev-xxx-public.example.info」が今回作成したかったサブドメインとなります。ルートドメイン「example.info」の配下、かつパブリックドメインの「dev-xxx-public」の配下となるような値としてホストゾーンを定義しています。ホストゾーンのタイプは「プライベート」、ホストゾーンの詳細ではブラウザなどからアクセスしたい先をAレコードとして定義しています。

一つ上の「dev-xxx-public.example.info」は「パブリック」ホストゾーンとなります。一番下の「local.dev-xxx-public.example.info」の「親」となるため、ホストゾーンの詳細では「local.dev-xxx-public.example.info」のNSレコードを保持しています。またこの「バブリック」ホストゾーンに紐づくACM証明書を発行するため、そのCNAMEも保持しています。これについては後述します。

ここまでがルートドメインとは別の「アカウントB」上でのRoute53定義となります。

一番上のルートドメイン「example.info」は「アカウントA」となります。このアカウントのホストゾーンは作業前から存在しているものです。直接の「子」ドメインとなる「dev-xxx-public.example.info」を委譲するため、ホストゾーンの詳細にて「dev-xxx-public.example.info」のNSレコードを保持しています。

証明書について

証明書についてはパブリック証明書とし、検証方法は「DNS検証」としました。この証明書は「local.dev-xxx-public.example.info」で使えるワイルドカード証明書とするため、ドメイン名は「*.」で始めています。 ACMで証明書を作成するとドメインやCNAMEの定義が見れますが、以下のようになります。